IBIS Macromodel Task Group Meeting date: 19 July 2016 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM * Luis Armenta Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Arpad noted that he had decided to remove the "Pin Reference Concerns" item from the agenda, as Bob had completed his presentation last week. He noted that any related discussions could continue under the "IO Buffer Reference Terminal" topic. No one objected. ------------- Review of ARs: - Ambrish to check for a collaborator's feedback on his nearly ready new version of the Backchannel proposal. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Radek: Motion to approve the minutes. - Bob: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Improved C_comp proposal: - Randy: [ sharing 'C_comp Model Using IBIS-ISS or Touchstone BIRD draft rev 1'] - We can walk through changes today and wait for comment and feedback offline. - BIRD text from the year-old draft moved into the new BIRD template 1.3. - Solution Requirements section: Updated based on feedback from the recent ATM meeting where we discussed it [May 31, 2016 ATM meeting]. - Text has been updated using newer language from the Interconnect BIRD draft. - Trying to tie it in better with how it might be used in the specification. - [Summary of Proposed Changes: section] - New C_comp Model. - Existing C Comp Corner keyword is required if using C_comp Model. - So EDA software can use the C values in C_comp Corner for computing the K-T compensation functions. - A new location can be specified for the Si_location and Timing_location Sub-Params. - Currently values are Pin and Die. Die should be interpreted as Pad. - Adding a new value "Buf" to refer to the Buf_rx* terminal(s) of a C_comp Model. - Discussion: Bob and Arpad noted that in the past pad and buffer terminal had been one and the same. Arpad noted that this is the first feature that will acknowledge the non-ideal connection between buffer terminal and die pad. Randy noted that this is a way to indicate to an EDA tool that we want a waveform measurement from a certain location (a new location). Arpad noted the [External Model] had provided some capability to observe the waveforms after the [External Model]. Walter said we may want to add "Pad" as an alias for the existing "Die" value, so that we can have Pin, Pad, Buf as is done in the Interconnect BIRD. Bob agreed with this idea. He noted that, unfortunately, without an on-die interconnect, this alias would still mean the Buf location. - [Usage Rules: section] - Added a sentence stating how the EDA tool may use C Comp Corner for the K-T extraction. - This is the only real statement on how the EDA tool could compensate for having this much more complicated C_comp Model. - Discussion: Arpad wondered if the "K-T" terminology should be changed to something more general to describe the issue more broadly. Radek noted that it could be better defined, but that the concept is already used in the spec for the power aware models [ISSO_PU, ISSO_PD keywords: note, however, that terminology in that section is of the form Kpu(t) and Kpd(t)]. Bob said he felt that this BIRD should only be concerned with the location of electrical terminal connections. The group agreed to consider this terminology later, with suggestions including "compensation algorithm", "waveform processing", and "v(t) curve shaping". - [Sub-Params of C_comp Model] - Param (optional, only valid with File_IBIS-ISS) - File_IBIS-ISS (either this or File_TS is mandatory). - File_TS (either this or File_IBIS-ISS is mandatory). - Number_of_terminals (mandatory). - Param - Used for passing parameter values into an IBIS-ISS subcircuit. - Unlike in the Interconnect BIRD, we need to be able to pass in corner values. - Can pass in a single value or a corner type value. - [Number_of_terminals and Terminal line rules:] - The intent is that we don't want to have to deal with a 50 terminal subcircuit and how to terminate all the terminals that don't correspond to a C_comp Model terminal. - The number of terminals in the subcircuit should match the number of terminals defined for the C_comp Model connection. - Discussion: Arpad asked if the intention of this was that a five terminal subcircuit could not be connected to a 3 terminal buffer model. Walter said that this was the intent, and that, for example, an Input model with only pc, gc, and input terminals would use a 3 terminal subcircuit for its C_comp Model. Bob, Radek and Arpad expressed concern about this concept, and noted that a terminal might exist in the model even if no I/V table were defined for it, or that it might not be clear what the terminal count should be if two terminals, such as pu and pc, were tied together. Arpad noted that two *_ref terminals having the same [* Reference] value would not imply that they could be treated as tied together, since the package model might connect to them differently. Radek summarized by stating that we have possible terminals to connect to, and we have the actual number of terminals for the model at hand, and we need to specify them properly. He noted that he still objects to the fact that there is still no provision for providing the reference terminal for the I/O signal, which would make it impossible for this C_comp Model to fall back to model the standard C_comp. Walter pointed out that Ext_Ref was one of the available Terminal_type definitions and could be specified. Radek felt that Ext_ref generally has a different purpose and meaning. - [Figure Y:] - If your C_comp Model has some series resistance or inductance elements, then you can separate out new internal nodes for the input and output. - Discussion: Radek expressed concern about the use of Buf_I/O and DIE-PAD together on the right hand side of the figure. Randy and Walter said the C_comp Model is at the buffer level, but the figure assumes there might be some on-die interconnect between them. Randy noted that this on-die interconnect might even be built into the C_comp Model itself. Radek felt the figure could cause confusion given the explicit mention of Die, Pad, Buf added in the Si_location discussion. Walter noted that the appearance of Buf_I on the right hand side of the figure made it look like Buf_I was in input to the model along with the four rail voltages. Randy said it was his graphical attempt to show that the new model allows for access to all five of these terminals. Bob asked if this "Buf_I" was a modal connection, in receiver mode there is no Buf_O, and in driver mode there is no Buf_I? He suggested the possibility of switching in one C_comp Model for driver mode and another for receiver mode. Walter said that he had thought of it differently, and thought of Buf_I as a pc curve and a gc curve, and Buf_O as a pu curve and a pd curve turned on and off by K(t) functions. When not in driving mode, you would just get pc and gc. Radek said that he thought Bob's idea for two distinct C_comp Models for the two different modes of an I/O might be quite simple and elegant. He felt it would allow all the capabilities shown in the figure without forcing the model maker to deal with the complexity of combining the two modes. Randy agreed that he liked the idea, and noted that he currently does something similar when he wants to specify a different C_comp value for the driver mode vs. various termination modes. - [Figure Z: Differential C_comp Model] - I have introduced language for a differential C_comp Model. - I also prepared a version in which I simply removed this section. - For single ended and pseudo-differential buffers we work fine with the single ended form of C_comp. - If we want a true differential model, the only we can currently do that is with [External Model], but in that case C_comp is ignored altogether because it's assumed everything is wrapped up in the [External Model]. - I'm therefore wondering if this differential C_comp Model would not be very useful. - Discussion: Walter noted that the approach shown in the figure had actually proven useful for a sort of pseudo-differential approach where a "parallel termination" (connection between the Buf_I/O_pos and Buf_I/O_neg) could be could be created via a subcircuit. Radek noted that there was currently no way to specify such a connection, given that it was made up of two single ended buffers and [Diff Pin] currently has no provision to specify the connection of this type of model. Walter agreed that this would require an extension to the specification. Arpad noted an editorial suggestion based on Radek's earlier comments, and suggested that "DIE-PAD" be replaced with "buffer terminal" on the right hand side of figures X, Y, and Z. - Arpad: AR for Randy to get this proposal posted to the ATM work archives. IEEE P370 email discussion: - Walter: IEEE P370 has three subcommittees. - Intention is to create a document on how to get good s-parameter data, how to measure it and how to correct it for things like causality, etc. - This particular subgroup I'm on is doing the various analysis tools that one can do on s-parameter data. - This is a first draft written by the chair of the group. - I want to take all your feedback back to the committee. - Radek: I found it pretty disappointing. - It's an imprecisely stated mix of guidelines and actual requirements. - For example, stating that the current entering the plus terminal must equal the current minus terminal is correct. - On the other hand, you can't say a signal must be connected to a signal. First, you must distinguish between a signal and a signal terminal, and second you can't state that something must be done. You can say that there are certain consequences, but you can't say something "must" be connected a certain way. There are guidelines, and they should clearly be stated as guidelines or intent. - The goal of the project, as stated by Walter, is good. - Walter: If you want to daisy chain s-parameter blocks by connecting a port of one s-parameter block to a port of another, the assumption is that the reference terminal should have been more or less the same when both s-parameter blocks were measured. That's the point they're trying to make, and I think it's connected to our reference terminal discussions. - Two contexts for reference: - There's a voltage between two nodes, and one node is the "reference" node. - When you have I/O going out to the outside world it has to be imaged, on a plane, usually of its reference signal name. So there it means something different than it does inside the buffer. - Radek: If they're saying these are good guidelines, that's fine. - But saying these are requirements is not true at all. - Walter: They're not requirements for how to build the system. - They're saying that it's required that you measure things a certain way. - This is just a small subset of the project and not shown in context. - Radek: S-parameters have been used for many years in many contexts, so this document can't just take it over from previous users. - Walter: This document is strictly confined to s-parameter measurements of packages, connectors, boards, end-to-end. - They do this because the IEEE802.3 has a COM [Channel Operating Margin] that takes the s-parameter model of a channel from Tx pin to Rx pin, does some Fourier arithmetic and tells you if the channel will work. - If you're going to make the measurement for that test, you have to know how to make the measurement properly. - That's the background for this. - Arpad: Thank you all for joining. ------------- Next meeting: 26 July 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives